There have been several systems in recent years such as IBM's Infowindow product that integrates graphics with live video on one monitor. For a detailed description of the infowindow product, reference should be made to one of the following publications describing same.
1) "Infowindow Guide to Operations" Order No.: SK2T0297 and, PA1 2) "Infowindow Enhanced Graphics Adapter: Hardware Maintenance and Service Manual" Order No.: SK2T0298, Both are available from IBM Corp. Mechanisburg, Pa.
Typically, the graphics information is "overlayed" on top of the video; the background is a moving video image, with the foreground being comprised of various graphic objects, such as icons, menus, or text.
In order to display both elements on a single monitor, it is necessary to synchronize the video signal with the graphics signal, so that both rasters are the same size and are displayed at exactly the same rate. Furthermore, each video pixel should correspond one to one with a graphics pixel so that both types may be addressed in the same manner. One way to achieve these requirements is through the use of two separate frame buffers, one for graphics, and one for video, as described fully in U.S. patent application Ser. No. 4,314,623 of Lumelsky and Peevers, entitled "Audio Video Interactive Display", filed on Feb. 23, 1989, "Audio Video Interactive Display". The video information is read out of the dual-port VRAM based video buffer using the same synchronization and clock signals as are used for the graphics Frame Buffer.
The most common method for overlaying is known as "color keying", where the background color for the graphics information is defined as the "keying" color, with all pixels of that special color being replaced by live video in these positions on the monitor (refer to FIG. 1A). Pixels of all other colors are shown on the monitor unmodified. This same method can be used to show video "objects" in the foreground, on a graphics background. Here, the objects (which could be rectangular video "windows" or arbitrarily shaped objects) that are to be seen as video are drawn in the keying color, which is some color other than that of the graphics background (refer to FIG. 1B). Graphics objects can also be shown in the foreground, provided they are not drawn using the keying color.
FIG. 2 illustrates a typical circuit for implementing the color keying scheme. It is comprised of a register 200 to hold the digital value of the keying color, a digital comparator 202, and a fast (pixel speed) analog multiplexer 204. The n-bit key register is constantly compared with the n-bit digital representation of the graphics pixels that are about to be displayed. N is typically a number between 1 and 8 in todays graphics displays. When one of these incoming pixels has the same value as the key color, the output of the comparator is asserted. This causes the analog switch 204 to output the voltage of the video signal at that instant. For any other color of input pixel the comparator will output the voltage of the analog graphics signal. The circuit shown is adequate for monochrome systems, where there is only one color component. With color graphics systems, one analog switch is necessary for each color component (typically three--one for each of Red, Green and Blue).
Typically, these overlay schemes are employed by dedicated, video-based application programs that control external video sources such as videodisk players, VCR's, etc. The user would start the application, which would in turn initialize the key register with a specific color and subsequently draw the graphics screen with the appropriate areas drawn with the keying color.
Several problems are encountered when one considers windowing, i.e., non-full-screen systems. These systems may have more than one application shown on the screen at a given time, especially with today's windowing, multitasking operating systems (e.g., the IBM OS/2 with Presentation Manager).
A first problem is encountered when the screen is shared by both video-based and non-video applications. The non-video applications typically know nothing at all about color keying, much less what color the current key is. They draw their various objects on the screen assuming that any color may be drawn and will be seen on the screen unmodified. As the video applications attempt to utilize the color key, various colored graphic objects in the non-video application will suddenly be replaced by video. Clearly, this is an unacceptable situation.
This problem is further complicated when multiple video applications are run concurrently on one screen. Essentially, the multiple applications will contend for one resource: the color key register. When a given application is running, it may modify the key register for its own purposes. This may cause disturbing effects in other application windows, since they may have drawn graphic objects in the same color as the new keying color. When the key register is modified, these objects will suddenly appear as video objects on the screen, which is almost certain to be undesirable from the user's standpoint.
A second problem is encountered when it is desired to use static video images on a common screen along with motion video and graphics. An example of this is shown in FIG. 3, where a still video snapshot is placed in a graphics window which is presented on a motion video background. The same buffer is being viewed in both the still video window and the moving video background, i.e., video overlay is taking place in both of these regions of the screen. In general, this situation may result whenever the high-color content capabilities of the video buffer are desired to present quality static images along with graphics while motion video is occurring in the background.
The difficulty is that the still region must somehow be protected from being overwritten by the surrounding process of sampling the live video background. As the new video information is stored into successive locations of the video buffer, those locations that store the static image will be corrupted, unless the sampling process is somehow prevented in this region.
Accordingly there is a need for a system that will solve these problems which is effective, reasonable in cost and, most importantly, can achieve these results in mixed application systems as described above.